1. The Field of the Invention
The present invention relates to maintaining authentication states for resources that are accessed in a stateless environment. More specifically, the present invention relates to systems, methods, and computer program products for validating user authentication information that is transported via stateless protocols.
2. Background and Relevant Art
Content on the World Wide Web (“WWW”) is typically accessed in a client/server model. A “Web browser” of a client computer system sends a request to access content that is provided by a “Web Server” of a server computer system. If the user of the Web browser is authorized to access the content, the Web server typically provides the content to the Web browser.
Web browsers and Web servers include software modules that request, provide, and transport content, and that operate at various layers in the Open System Interconnection (“OSI”) model. The OSI model defines one possible framework for implementing protocols in different functional layers. The OSI model breaks down the operations for communicating data into seven distinct “layers,” each designated to perform certain operations in the data transfer process. Although the communication frameworks that have actually been implemented do vary somewhat from this model, referring to the OSI model is useful for understanding basic data communication.
Typically, the top layers of the OSI model are implemented by application software, while the lower layers of the OSI model are relegated to the operating system. The top-most layer is the application layer, which is typically responsible for supporting applications and end-user processes. When data is sent from a computer system, the data typically originates from the application layer, is passed down through lower layers, and enters onto a physical network. Likewise, when data is received at a computer system, the data enters from a physical network, is passed up through lower layers, and is transferred to the application layer.
In a Web environment, content and requests for content, are frequently transported using Hypertext Transfer Protocol (“HTTP”). HTTP operates between the application layer and other lower layers of the OSI model to facilitate the transfer of content in a Web environment. A request to access content typically originates from a user at a Web browser. The request is then converted to HTTP, passed through lower layers of the OSI model, and sent from the browser client computer system across a network. The request is received at a server computer system that includes a Web server, passed through the lower layers of the OSI model, and then converted to HTTP. After being converted to HTTP, the Web server may process the request to determine if the user of the Web browser is authorized to access the requested content. If the user is authorized to access the requested content, the Web server will transport the content back to the Web browser via HTTP in a manner similar to how the request was transported.
HTTP is a stateless protocol. In other words, communication via HTTP (e.g., a Web page request) is performed without knowledge of any previous communication (e.g., other previous Web page requests). As such, HTTP authentication does not support the concept of a “session” where a user would “log-in” or “log-out.” Each request to access content that is transported via HTTP (hereinafter called “an HTTP request”) must include appropriate HTTP authentication information.
The HTTP protocol provides for this authentication information to be supplied with each HTTP request via a special header called the WWW-Authorization header. This authorization header is of the format “WWW-Authorization: [Authentication-Type] [Credentials].” The way the browser obtains and transmits these credentials is as follows: The first time a user tries to access a web site which requires authentication, the web server will refuse to provide the requested content and will return to the browser an HTTP Error message number 401—Unauthorized, and this response contains a header line with the text: “WWW-Authenticate: [realm] [Authentication methods supported] [Optional information]”.
When the browser receives this message it pops up a dialog box, which requests the user's name and password. After the user types in a correct password, the browser retransmits the original HTTP request to the server but it adds the HTTP “WWW-Authorization” header that now includes the credentials as an argument of the header label. If the Web server accepts the included credentials and returns valid content, the browser caches these credentials and retransmits them with each new request to this same Uniform Resource Locator (“URL”) or derivative relative URL's associated with the same content.
The storage of user credentials in browser memory presents at least one potential security risk. Web browsers collect credentials and usually store them in cache memory indefinitely until a browser program is made to exit (by quitting the browser program or re-booting or turning off the computer (client device)). Thus, the credentials of a user who accessed protected content may be stored in cache memory of a browser even after the user is no longer using the browser.
This may be especially problematic in locations that have public computers. A privileged user may access protected content (content requiring credentials to access) through a browser contained in a public computer or client device (e.g., a public Kiosk). As a result of accessing the protected content, the privileged user's credentials are cached in browser memory. If the privileged user then steps away from the public computer, a non-privileged user may come along and use the browser's back-button or history feature to access the protected content. The non-privileged user would be able to access the protected content because the browser would retransmit cached credentials when the non-privileged user visits a URL that the privileged user previously visited.
Similar risks also apply to portable devices, such as, for example, mobile telephones or personal digital assistants, with Web browsers. For example, a non-privileged user might find a mobile device that contains a currently active Web browse (i.e., the portable device is turned on). The non-privileged user may be able to access protected content on the portable device by visiting a URL that causes the Web browser to retransmit cached credentials of the owner of the portable device.
In most public computers and portable devices that contain Web browsers, there is no easy way for a user to remove their credentials from the Web browser cache. Even if it is possible to remove credentials from memory (such as powering off the device or exiting the browser) a user may forget to remove their credentials when they are finished using a Web browser. Thus, it is necessary to provide some level of security to mitigate the effects of a user forgetting to remove their credentials.
The most secure method of using credentials would be for a browser to require users to manually re-enter authentication information for each HTTP request to access content. However, a typical interaction with a Web site could consist of tens or hundreds of HTTP requests. Thus, reentering credentials for each HTTP request would significantly increase the amount of time needed to access content and may be annoying to users.
Due to the danger of persisting HTTP authentication information stored in browsers, some content provider modules may implement their own application layer log-in state. For example, a Web page may control access to itself using application layer authentication, as opposed to allowing a Web server to control access to the Web page using HTTP authentication. This is often done by a content provider module introducing a “forms-based” log-in where a user manually enters content provider authentication information instead of HTTP authentication information. When a user is successful at logging-in, the content provider module, as opposed to the Web server, sends a logged-in cookie to a Web browser. Every time a new request is received, the content provider module checks the logged-in cookie. If the content provider module senses the logged-in cookie, the content provider module realizes that the user of the Web browser is logged-in.
Such content provider modules may also implement their own application layer log-out state. In response to a user clicking on a log-out link, the content provider module unsets, or deletes, the logged-in cookie from the Web browser. A content provider may also replace the logged-in cookie with a logged-out cookie. When the next request comes into the content provider module, the content provider module senses that a user is logged-out and refuses to provide content to the Web browser. The only way for a new user to gain access is to manually complete the forms-based log-in.
Thus, the conventional method for solving the problem of cached HTTP authentication information is to not use HTTP authentication at all, but to introduce application-based authentication session management using Application Forms to prompt a user for authentication information, and to store this information in “cookies.” Cookies are small text files that include information about a Web browser, such as a user name and password associated with a user of the Web browser. The first time the browser requests content from the application, the application sends a form to the user requesting the user's name and password. The application then authenticates the user, and if this authentication is successful, the application will encode a cookie with a validated (time stamped) “admission ticket” which is usually good for that one session. The cookie is associated with the requested content and the Web server sends the cookie back to the Web browser where the cookie is stored. In subsequent requests to access the requested content, the authentication information included in the cookie (i.e. the admission ticket) is automatically transmitted to the Web server. Thus, if a user frequently accesses the same content, the user does not have to manually reenter the authentication information each time the same content is accessed.
While application level session management provides more secure access to content, through the use of logged-in and logged-out cookies, it is also cumbersome to a content provider module that employs such a scheme. It requires a content provider module to manage a separate authentication infrastructure, including the management of specialized access cookies. This is problematic for at least two reasons. Web servers or proxy servers typically control access to content at the HTTP level, while allowing content provider modules to focus on the management and delivery of content. Consuming the resources of a content provider module for session management leaves a reduced amount of resources for providing content. Also, HTTP authentication is well integrated into a variety of operating systems. However, a separate authentication infrastructure, such as one managed by a content provider module, may require significant coding modifications for compatible operation with the variety of operating systems.
Some content provider modules have found solutions to the danger of persisting HTTP authentication information stored in cookies without resorting to application layer session management. In one mechanism, a log-out action of a user may result in an exit signal back to a Web browser, which causes the Web browser to drop all cached user-ids and passwords that may be stored in cookies. Another mechanism causes a script to run on a client computer system. The script utilizes a proprietary Web browser Application Program Interface (“API”) to clear cached credentials, such as those contained in a cookie. However, these mechanisms are Web browser dependent and a Web browser may require modification to ensure compatibility with these mechanisms. Moreover, these mechanisms do not address the needs of devices that include Web browsers that never exit or do not include the proprietary APIs. For example, many cell phone based Web browsers never exit and do not include the capability to run scripts.
Therefore, what are desired are systems, methods, and computer program products for maintaining authentication states for resources that are accessed via stateless protocols, wherein the systems, methods, and computer program products utilize the authentication mechanisms included in the stateless protocols.